1. Technical Field
This disclosure relates to methods and systems supporting computing and data processing systems. Specifically, the disclosure relates to definition, creation, management, transmission, and monitoring of errors in a Services Oriented Architecture (SOA) environment.
2. Related Art
In SOA, there are typically many communicating reusable services that are deployed in several machines. In large-scale enterprises, like eBay, eTrade, or Google, for example, there could be thousands of different services deployed in thousands of machines. It is most common and efficient for these automated services to communicate with each other. Further, external access is also typically provided for some of these services. In communicating with each other, various different types of communication protocols may be used for efficiency and optimization reasons. Communication between service providers and service consumers can be accomplished using some pre-defined protocol. In the web services case, this protocol can be the Simple Object Access Protocol (SOAP). SOAP is a protocol for exchanging Extensible Mark-up Language (XML)-based messages over computer networks, normally using Hypertext Transport Protocol (HTTP/HTTPS).
No matter how perfectly software is implemented, often times, certain things go wrong and we need a simple and clear mechanism to communicate exactly what went wrong to the callers/users. It is also vital that we need to standardize and follow a common mechanism for describing not only what an error means, but also to propagate such messages consistently and uniformly to the callers. Errors are essentially a result of abnormal processing of the request. This could be due to invalid input/request from the caller, or due to some business error or unexpected system errors. Regardless of what the error is, we need a consistent way to define, create, manage, and transmit the details of the error, to enable service developers and service consumer developers to do error processing efficiently.
In a SOA environment, service errors can be defined as any condition indicating complete or partial failure of a service operation, regardless of how this condition is signaled in the whole service processing flow. In this sample definition, service errors in SOA can come in two forms:                Faults: Declared in the Web Services Description Language (WSDL) as Fault messages and transmitted from services to consumers in a out of band payload. In the case of SOAP protocol, it is the SOAPFaults, transmitted as exceptions in Java language bindings;        Response-Resident Errors (RRE): Errors transmitted as part of the normal response payload of operation execution.        
In both of these scenarios, the structure of the error can be commonly defined for uniformity, consistency and for uniquely identifying errors across an organization. These errors can be originated from:                The service implementation when the service application business logic detects application errors, and        The SOA runtime when it detects system level errors.        
In the absence of special measures (e.g., modeling techniques/implementation enhancements, etc.), there can be a divergent processing flow for service errors. This complicates client processing, especially for non-SOA clients and for 3rd party coders; because, in most cases, processing flows must be anticipated. Additionally, for response-resident errors, in the absence of additional framework or application implementation, most of the SOA value-added processing is missed. A framework is a system, such as an application, within which a error processing mechanism is implemented.
Thus, a computer-implemented system and method for the definition, creation, management, transmission, and monitoring of errors in a SOA environment is needed.